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Abstract 

In this work we recast some design principles com- 
monly used in software engineering and adapt them 
to the design and analysis of domain descriptions 
in reasoning about actions. We show how the infor- 
mal requirements of cohesion and coupling can be 
turned into consistency tests of several different ar- 
rangements of modules. This gives us new criteria 
for domain description evaluation and clarifies the 
link between software and knowledge engineering 
in what concerns the meta-theory of actions. 



1 Introduction 

Among the principles of the object-oriented paradigm are the 
following: 

1. Work with modules (or components, functions, etc.). 

2. Minimize interactions between such modules. 

3. Organize the modules into well-defined layers to help 
minimize interactions. The goal is to have components 
of one layer using only components from immediate 
neighbors, wherever possible. 

4. Anticipate what kind of extensions or modifications 
might be made in the future, and support this at design 
time so that one can extend the system with minimal dis- 
ruption later. 

There seems to be an agreement that such principles for 
object-oriented programming or design are the same as for 
knowledge representation. To witness, the design of domain 
descriptions in reasoning about actions has much more in 
common with software engineering than one might think: in 
the same way as for software projects, one can talk about con- 
sistency, evolution and correctness of domain descriptions. 

All the principles above can be applied to the design of do- 
main descriptions, too. We argue that a good domain descrip- 
tion should be one whose consistency check and maintenance 
complexities are minimized, so that any further modification 
is localized, with a bounded scope. 
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With this in mind, one can see the specification of domain 
descriptions as a task similar to project development in soft- 
ware engineering: Item 4 above is what has been called elab- 
oration tolerance [McCarthy, 1988]. In this way a represen- 
tation is elaboration tolerant to the extent that the effort re- 
quired to add new information (a new action or effect) to the 
representation is proportional to the complexity of that infor- 
mation [Shanahan, 1997]. Items 1, 2 and 3 reflect the concept 
of modularity, which means that different modules have no 
elements in common. Such a notion of modularity is going to 
lead us along the present work. 

This paper is an elaboration of the results we have pre- 
sented in [Herzig and Varzinczak, 2004]. Here we pursue the 
following plan: in Section 2 we recall some important con- 
cepts from software engineering; after discussing the ontol- 
ogy of dynamic domains (Section 3) we apply the concepts 
of Section 2 to the design of domain descriptions (Sections 4 
and 5) making a step towards formal criteria for domain de- 
scription evaluation. In Section 6 we present the main results 
that follow from our approach, and before concluding we ad- 
dress related work found in the literature on this subject. 

2 Some principles of software engineering 

One of the first steps in software development is that of ab- 
straction. Abstraction consists mainly in rendering lower- 
level details invisible to upper levels in order to facilitate the 
understanding and design of complex systems. As an exam- 
ple, a specification of a data or knowledge base query does 
not need to take into account the algorithmic process that will 
be carried out in order to answer the query. 

In parallel to abstraction, one of the most important guide- 
lines in project design is that of modularity: dividing the soft- 
ware into modules, based on their functionality or on the simi- 
larity of the information they handle. This means that instead 
of having a "jack of all trades" program, it is preferable to 
split it up into specialized subprograms. For instance, a pro- 
gram made of a module for querying a database and a module 
for checking its integrity is more modular than a single mod- 
ule that does these two tasks at the same time. 

Among the major benefits of modular systems are reusabil- 
ity, scalability and better management of complexity. 

There is more than one way to split up a program. One 
of the most used techniques is that of forcing functional in- 



dependence of its modules. One ensures functional indepen- 
dence in a project by defining modules with only one pur- 
pose and "aversion" to excessive interaction with other mod- 
ules [Pressman, 1992]. 

Among the criteria commonly used for evaluating func- 
tional independence of modules (and thus how modular a 
piece of software is) are the informal notions of cohesion and 
coupling. 

Cohesion is how closely related pieces of a single compo- 
nent are to each other. A module is cohesive when at the high 
level of abstraction it does only a single task. The more a 
module is focused on a precise goal the more it is cohesive. 

A highly cohesive module will be simpler to understand, 
having to do only a single task, while a lowly cohesive mod- 
ule, performing so many tasks, will be difficult to understand. 

It is difficult to reuse a task-overloaded module, while a 
highly cohesive module is simpler to reuse and to extend. 

Coupling is the interdependency between a method and the 
environment (other methods, objects and classes). Low cou- 
pling means to keep dependencies (communication, informa- 
tion sharing) between components at a minimum. 

A design that has low coupling is more amenable to 
change, since it reduces the probability of changes cascading 
and affecting a larger part of the system. 

Unanimously in object-oriented development, the best way 
to design a software is to have low coupling and high cohe- 
sion. We sum this up in two informal design principles: 

PI. Maximal cohesion: Every module should be conceived 
in such a way that it is maximally cohesive. 

P2. Minimal coupling: All modules should be conceived in 
such a way that they minimize coupling. 

3 Natural modules in domain descriptions 

Like in object-oriented programming, in describing a domain 
different entities should be separated in different modules. 
Moreover, each module should be conceived in such a way 
that it has no direct access to the contents of the others. In 
reasoning about actions, accessing a module means using it 
to perform reasoning tasks like prediction, postdiction, plan- 
ning and others. This amounts to using its logical formulas 
in inferences. In this section we establish the ontology of do- 
main descriptions and present the way we arrange in different 
modules the axioms commonly used to describe them. 

Every domain description contains a representation of ac- 
tion effects. We call effect laws formulas relating an action 
to its effects. Statements of conditions under which an ac- 
tion cannot be executed are called inexecutability laws. Ex- 
ecutability laws in turn stipulate the context where an action 
is guaranteed to be executable. Finally, state constraints are 
formulas that do not mention actions and express constraints 
that must hold in every possible state. These are our four in- 
gredients that we introduce more formally in the sequel. 

If we think of a domain description as a software appli- 
cation, we can imagine its organization in an object-oriented 
view and attempt to have a kind of class diagram for it. This 



is illustrated by Figure 1, where we can see the relationship 
among the different types of entities. 

A domain description consists of a description of effects 
of actions, their non-effects, executabilities, inexecutabilities 
and also state constraints that do not depend on any particular 
action. 



domain description 



effects 




non-effects 



state constraints 



Figure 1 : "Class diagram" of modules in designing domain descrip- 
tions. Edges represent has-a relations. 

Among the effects of actions, we can distinguish direct ef- 
fects and indirect effects (ramifications). 

Non-effects of actions are related with the frame prob- 
lem [McCarthy and Hayes, 1969], and indirect effects with 
the ramification problem [Finger, 1987]. In this work we 
abstract from these problems and assume we have a con- 
sequence relation powerful enough to derive the intended 
conclusions. We suppose given a 'doped' consequence re- 
lation |=s , which encapsulates some traditional approach in 
the literature (e.g., [Schubert, 1990; Lin, 1995; McCain and 
Turner, 1995]), with which all intended frame axioms and in- 
direct effects can be derived, and we use it henceforth. As 
examples we have 

{loaded(s)} |=a loaded(do(wait,s)) 

(i.e., waiting does not change the status of loaded) and 



walking (So), 

walking (s) — > alive (s), 

-ialive(do(shoot, s)) 



f« -<walking(do(shoot, So)) 



Hence shooting has the indirect effect that the victim will no 
longer be walking. 

We use small letters to denote variables, and capital letters 
to denote constant symbols. Free variables are supposed to 
be universally quantified. 

To sum it up, our main concern here will be with direct 
effects (henceforth effects), inexecutabilities, executabilities 
and state constraints. We introduce this in what follows. 

Effect laws Logical frameworks for reasoning about ac- 
tions contain expressions linking actions and their effects. We 
suppose that such effects might be conditional, and thus get a 
third component of such axioms. An effect law for action a is 
of the form 

Poss{a, s) -> ($(s) ->• y(do(a,s))) 

where 3>(s) is a simple state formula about situation s, and 
^(do(a, s)) is a. simple state formula about situation do(a, s). 

A simple state formula about a situation term t contains no 
PoM-predicate and no situation terms other than t [Lin, 1995]. 

An example of effect law is 

Poss(shoot,s) — > (loaded(s) — > -^alive(do(shoot,s))), 
saying that whenever shoot is executable and the gun is 
loaded then after shooting the turkey is dead. Another one 
is Poss[tease, s) — > walking(do(tease,s)): the result of teas- 
ing is that the turkey starts walking. 



Inexecutability laws The design of domain descriptions 
must also provide a way to express qualifications of actions, 
i.e., conditions under which an action cannot be executed 
at all. An inexecutability law for action o is of the form 

$(s) -» ~^Poss(a, s) 

where $(s) is a simple state formula about s. 

For example, -iHasGun(s) — > -<Poss(shoot, s) states that 
shoot cannot be executed if the agent has no gun. 

State constraints (alias domain constraints) Frameworks 
allowing for indirect effects make use of formulas that link 
invariant propositions about the world. Such formulas char- 
acterize the set of possible states. A state constraint is a sim- 
ple state formula about the situation term s that is consistent. 
An example is walking (s) — > alive (s), saying that if a turkey 
is walking, then it must be alive [Thielscher, 1995]. 

Executability laws With only state constraints and effect 
laws one cannot guarantee that action shoot is executable if 
the agent has a gun. An executability law for action a is of 
the form $(s) — > Poss(a, s), where $(s) is a simple state 
formula about s. For instance HasGun(s) — > Poss(shoot, s) 
says that shooting can be executed whenever the agent has a 
gun, and Poss(tease, s) that the turkey can always be teased. 

Whereas all the extant approaches in the literature that al- 
low for indirect effects of actions contain state constraints 
and effect laws, the status of executability laws is less con- 
sensual: some authors [Schubert, 1990; Doherty et al, 1996; 
McCain and Turner, 1995; Thielscher, 1995] more or less tac- 
itly consider that executability laws should not be made ex- 
plicit but rather inferred by the reasoning mechanism. Others 
[Lin, 1995; Zhang et al, 2002] have executability laws as first 
class objects one can reason about. 

We nevertheless would like to point out that maximizing 
executability, as usually done in the literature, is not always 
intuitive: suppose we know that if we have the ignition key, 
the tank is full, . . ., and the battery tension is beyond 10V, 
then the car (necessarily) will start. Suppose we also know 
that if the tension is below 8 V, then the car will not start. What 
should we conclude in situations where we know that the ten- 
sion is 9V? Maximizing executabilities makes us infer that it 
will start, but such reasoning is not what we want if we would 
like to be sure that all possible executions lead to the goal. 

It seems a matter of debate whether one can always do 
without executabilities. We think that in several domains one 
wants to explicitly state under which conditions a given ac- 
tion is guaranteed to be executable, such as that a robot should 
never get stuck and should always be able to execute a move 
action. In any case, allowing for executability laws gives us 
more flexibility and expressive power. 

Domain descriptions Given the four types of entities de- 
fined above, we arrange them in the following way: for a 
given action a, Eff a is the set of its effect laws, Inex a is the 
set of its inexecutability laws, and Exe a is the set of its ex- 
ecutability laws. Stat denotes the set of all state constraints 
of a given domain. Thus, Eff a , Exe a and Inex , for each 
action o, and Stat are the natural modules we consider here 
in designing a domain description. 



For parsimony's sake, we define Eff = |JEff a , Inex = 
|J Inex a , and Exe = |J Exe . We suppose all these sets are 
consistent. 

A domain description D is a tuple of the form 
(Eff, Inex, Exe, Stat). 

Once the information contained in a module is not mixed 
with others', it can be expected that undesirable side effects 
due to further modifications are less likely to propagate to 
other parts of the domain description. The same thing can be 
obtained for the consistency check if beyond of being sepa- 
rated the modules are designed in such a way that their inter- 
action is minimized. This is what we address in this section. 

As we have seen, in software engineering functional inde- 
pendence is evaluated by means of two criteria: cohesion, a 
criterion for evaluating the relative functional strength of a 
module, and coupling, an assessment of relative interdepen- 
dence among different modules. Both these notions are quite 
informal, even in software engineering, and cannot be mea- 
sured in an objective way. 

Here we explore these concepts when applied to domain 
descriptions and show how the informal requirements of soft- 
ware engineering can be turned into tests of consistency of 
several different arrangements of modules. 

4 Cohesion 

Normally cohesion comes with modularization, and its eval- 
uation depends mainly on the entities that one takes into ac- 
count when describing a domain. 

In talking about sets of logical formulas we take cohesion 
as how simple or well-defined a logical module is, consider- 
ing the different types of formulas that can be derived from it. 
We thus refine our first design principle: 

PI'. The less types of laws a given module entails alone, the 
more cohesive it is. 

As an example consider the following module: 

J ^HasGun(s) —¥ ^Poss (shoot, s), 1 
1 HasGun(s) — > Poss(shoot, s) J 

From such a set alone one can derive both -^HasGun(s) —> 
-<Poss(shoot, s) and HasGun(s) — ► Poss(shoot, s), which are 
formulas of two different kinds. In this case we say that such a 
set is a lowly cohesive module, for alone it functions to derive 
executabilities and inexecutabilities. A better approach would 
be to decompose such a module into the following ones: 

IneXshoM = {-<HasGun(s) — > -<Poss (shoot, s)} 

Exe s / 700( = {HasGun(s) — > Poss (shoot, s)} 

Total cohesion is not always easy to achieve. Suppose, for 
instance, a hypothetical situation in which we reason about 
the effects of drinking a cup of coffee: 



Eff, 



drink 



Poss (drink, s) — > 

(sugar(s) — > happy (do (drink, s)), 

Poss (drink, s) — > 

(salt(s) — » -thappy (do (drink, s)) 



Then, Eff^/ni entails (sugar(s) Asalt(s)) — > ^Po ss (drink, s). 
This means that from E&drink alone we do not get only effect 



laws but also inexecutability laws. Therefore Eff drink is n °t 
as cohesive as one might have expected. 

One step towards augmenting cohesion of a module of ef- 
fect laws can be by completely specifying the preconditions 
of effects of actions. For example, the weaker effect laws 



Stati 



J walking (s) — > alive(s), 1 
1 dead(s) «-> -iafive(s) J 



Effdrink 



Poss (drink, s) — > 

(sugar(s) A -isalt(s)) — ► happy(do(drink,s)), 

Po ss (drink, s) — > 

(salt(s) A -i5«^ar(s)) — » -ihappy(do(drink, s)) 



guarantee a higher cohesion of module Eff^„-„ t in comparison 
to that of Eff dnnife. 

By the definition of Stat, it is easy to see that from the 
state constraints we can derive formulas of any type, so Stat 
is by nature a lowly cohesive module. 

We are thus interested in refining even more our principle 
of high cohesion PI' by the following ones: 

Pl'-l. Iflnex|=3$(s),then0 |=3 $(s). 

Pl'-2. If Inex |w $(s) ->• Poss(a,s), then |=3 $(s) -> 
Poss(a, s). 

Pl'-3. IfExe|=3$(s),then0|=3$(s). 

Pl'-4. If Exe|=3$(s) ->■ -./to(a,s), then |=3 $(s) -> 
^Poss(a, s). 

Pl'-5. If Exe |=s /*m(a,s) -»■ ($(s) -»■ $(rfo(a,s))), then 
|=a /»ojj(a, s) -» ($(s) -> *(do(a,s))). 

Pl'-6. If Eff |=3 $(s), then |=3 $(s). 

Pl'-7. If Eff [=3 $(s) -> /to(a,s), then f=3 $(s) -» 
Poss(a, s). 

Pl'-8. If Eff |=3 $(s) -> -,/*m(a,s), then |=3 $(s) -» 
-<Poss(a, s). 

All these principles say is that a formula of a given type 
entailed by a module of a different type must be a theorem of 
the logic. 

5 Coupling 

As we have seen, coupling evaluates how much a module is 
tied to or dependent upon other modules. We take as coupling 
of two or more sets of different types of action laws how much 
interaction among them is needed to derive a formula of a 
given type. Interaction here means sharing logical formulas. 
Now we refine our second design principle: 

P2'. The less new consequences two or several modules 
have, the less coupled they are. 

(The new consequences of modules Mi and M2 are those 
consequences of Mi U M2 that are not consequences neither 
of Mi nor of M2 alone.) 

For instance, consider the domain description Di: 

!Poss(tease,s) — > walking(do(tease, s)), 
Poss(shoot, s) — > 
(loaded(s) — ► ~^alive(do(shoot, s))) 

Inexi = {-ialive(s) — ► -<Poss(tease, s)}, Exei = 



Observe that to derive the domain constraint walking(s) — > 
-^dead(s) one only needs Stati, i.e., no other module is re- 
quired for that. On the other hand, to conclude dead(s) — > 
-tPoss(tease, s) one needs both Stati and Inexi. 

Totally decoupled descriptions are not common in appli- 
' cations of real interest. For the example above, it seems to 
be impossible to diminish the interaction between Stati and 
Inexi without abandoning the concept of state constraints. 

On the other hand, if Exei m our example contained 
Poss(tease,s), things would be different: in this case, with 
Inexi one would be able to infer the state constraint alive(s), 
but such a law cannot be derived from Stati alone. A higher 
degree of interaction between this set and the others is nec- 
essary in order to do that. In such a case one would say that 
there is a high coupling among Di's modules. 

The principle of minimal coupling P2' can be refined in 
two more specific design principles: 

P2'-l. No implicit inexecutability laws: 

if D |=3 $(s) -» -nPoss(a, s), then 
Inex, Stat |=3 3>(s) — >• -^Poss(a, s) 

P2'-2. No implicit state constraints: 

if D |=3 $(s), then Stat |= $(s). 

P2'-2 is a useful feature of descriptions: beyond being a 
reasonable principle of design that helps avoiding mistakes, 
it clearly restricts the search space, and thus makes reasoning 
easier. To witness, if D satisfies P2'-2, then its consistency 
amounts to that of Stat: 

Theorem 5.1 If D has no implicit state constraints, then 
D |=3 ± iff Stat |= ±. 

5.1 No implicit inexecutability laws 

Consider the following domain description D2: 



EfF? 



( 



Poss(tease,s) — > walking (do(tease, s)), 

Poss (shoot, s) — > 
{ (loaded(s) — ► -<alive(do(shoot, s))) 



Inex2 = Exe2 = 0, Stat2 = {walking (s) — » alive (s)} 

From Poss(tease, s) — > walking (do(tease, s)) it follows with 
Stat2 that Poss (tease, s) — > alive(do(tease, s)), i.e., in every 
situation, after teasing the turkey is alive: 

Eff2, Stat2 |=3 Poss(tease, s) — > alive(do(tease, s)) 

Now as D2 \a -ialive(s) — > -<alive (do (tease, s)), the sta- 
tus of fluent alive is not modified by the tease action, 
and we have Eff 2 , Stat 2 |=3 (Poss (tease, s) A ^alive(s)) — > 
(alive (do(tease, s)) /\^alive(do(tease, s))). From this it fol- 
lows D2 |sa -talive(s) — > -<Poss(tease, s), i.e., the turkey can- 
not be teased if it is dead. But Inex2, Stat2 \fc -^alive(s) — > 
-^Poss(tease,s), hence Principle P2'-l is violated. The for- 
mula -ialive(s) — > -<Poss(tease, s) is an example of what we 
call an implicit inexecutability law. 



In the literature, such laws are also known as implicit qual- 
ifications [Ginsberg and Smith, 1988], and it has been argued 
that it is a positive feature of reasoning about actions frame- 
works to leave them implicit and provide mechanisms for in- 
ferring them [Lin, 1995; Thielscher, 1995]. The other way 
round, one might argue as well that implicit qualifications in- 
dicate that the domain has not been described in an adequate 
manner: inexecutability laws have a form simpler than that of 
effect laws, and it might be reasonably expected that it is eas- 
ier to exhaustively describe them. (Note that nevertheless this 
is not related to the qualification problem, which basically 
says that it is difficult to state all the executability laws of a 
domain.) Thus, all the inexecutabilities should be explicitly 
stated, and this is what Principle P2'-l says. 

5.2 No implicit state constraints 

Executability laws increase expressive power, but might con- 
flict with inexecutability laws. For instance, let D3 be such 
that Eff"3 = Eff"2, Inex3 = {-ialive(s) — ► -<Poss(tease, s)}, 
Exe 3 = {Poss(tease, s)}, and Stat 3 = Stat 2 . (Note 
that Principle P2'-l is satisfied.) We have the unintuitive 
Inex3,Exe3 \a alive (s): the turkey is immortal! This is 
an implicit state constraint because alive(s) does not follow 
from Stat3 alone: P2'-2 is violated. 

The existence of implicit state constraints may thus in- 
dicate too strong executability laws: in our example, one 
wrongly assumed that tease is always executable. It may also 
indicate that the inexecutability laws are too strong, or that 
the state constraints are too weak. 

6 Results for a dependence based solution to 
the frame problem 

Given an axiomatic theory of actions with a solution to the 
frame and the ramification problems, we are interested in 
knowing whether domain descriptions encoded in it satisfy 
or not our set of design principles. Here we chose to use the 
modal framework of CAV-^, [Castilho et al., 1999], which 
has been shown to support Reiter's solution to the frame prob- 
lem [Demolombe et al., 2003] and also proposes an assess- 
ment of the ramification problem. 

Let trsitCaic be a translation of a domain description in 
CAV~^ into the Situation Calculus. Dependences a ~> I 
are translated into predicates dep(a, I), meaning that action a 
may cause literal I to be true. The extension of dep is then cir- 
cumscribed (cf. Schubert's explanation closure assumption). 
As examples, dep (shoot, -iwalking) means that shoot may 
cause walking to be false, and the absence of dep (tease, alive) 
induces the frame axiom -ialive(s) — > -<alive(do(tease , s)). 

Theorem 6.1 HDcav^ is a domain description in CAV-^,, 
then trsitCaic (J^CAV^, ) satisfies Principles Pl'-l — PI '-7. 

Even in CAV^,, however, it is possible to derive inexe- 
cutabilities from Eff (see the example in Section 4), which 
violates Principle PI '-8. Establishing maximal cohesion of 
Eff in this case involves weakening of preconditions of ac- 
tion effects. Anyway, conceiving an algorithm to accomplish 
this task is not difficult (due to space limitations we omit its 
presentation here). 



Checking whether a domain description satisfies Princi- 
ple P2'-2 can be made with little adaptation of the material 
on the subject present in the literature [Zhang et al., 2002; 
Lang et al., 2003; Herzig and Varzinczak, 2004]. We do not 
deepen into further details here, and just present the main re- 
sults that we obtain when considering descriptions that satisfy 
the design principles that have been proposed (due to space 
limits no proof is given). 

Theorem 6.2 Let D be the translation into Situa- 
tion Calculus of a domain description in CAV^. 
If D has no implicit state constraints, then 
V\aPoss(a,s) ->• ($(s) -> *(do(o,s)))iff 
Eff a ,Inex ,Stat \aPoss(a,s) ->• ($(s) -» ^!(do(a,s))). 

This means that under P2'-2 one has modularity inside Eff, 
too: when deducing the effects of action a we need not con- 
sider the action laws for the other actions. Versions for exe- 
cutability and inexecutability can be stated as well. 

Theorem 6.3 There exist descriptions D not satisfying P2'-2 
such that D \a Poss(a, s) -» ($(s) -» i S(do(a,s))) and 
Eff a ,Inex a ,Stat #>Poss(a,s) ->■ ($(«) ->■ V(do(a,s))). 

For example, just take D3 as before: 

D3 \a Poss(shoot, s) — > (-<alive(s) — ► alive(do(shoot,s))), 
however Fiff 3shoot , Inex 3shoot , Stat 3 $> Poss(shoot,s) — > 
(-ialive(s) — » alive(do(shoot,s))). 

7 Related work 

Pirri and Reiter [1999] have investigated the metatheory of 
the Situation Calculus. In a spirit similar to ours, they use 
executability laws and effect laws. Contrarily to us, their 
executability laws are equivalences and are thus at the same 
time inexecutability laws. There are no state constraints, i.e., 
Stat = 0. For this setting they give a syntactical con- 
dition on effect laws forcing them not to interact with ex- 
ecutability laws, which precludes implicit state constraints. 
Basically, the condition says that when there are effect laws 
Poss(a,s) -» ($(s) -> §(do(a,s))) and Poss(a,s) -> 
(<&'(«) — ¥ <&'(do(a,s))), then $(s) and $'(s) are inconsis- 
tent (which essentially amounts to having in their domain de- 
scriptions a kind of "implicit state constraint schema" of the 
form -.($(«) A $'(«))). 

This then allows them to show that such descriptions are al- 
ways consistent. Moreover they thus simplify the entailment 
problem for this calculus, and show for several problems such 
as consistency or regression that only some of the modules of 
a domain description are necessary. 

Amir [2000] focuses on design and maintenance of ac- 
tion descriptions applying concepts of the object-oriented 
paradigm in the Situation Calculus. In that work, guidelines 
for a partitioned representation of a given description are pre- 
sented, with which the inference task can also be optimized, 
as it is restricted to the part of the domain description that is 
really relevant to a given query. This is observed specially 
when different agents are involved: the design of an agent's 
description can be done with no regard to others', and after 
the integration of multiple agents, queries about an agent's 
beliefs do not take into account the belief state of other agents. 



In that work, executabilities are as in [Pirri and Reiter, 
1999] and the same condition on effect laws is assumed, 
which syntactically avoids implicit state constraints. 

Despite of using many of the object-oriented paradigm 
tools and techniques, no mention is made to the concepts of 
cohesion and coupling. In the approach presented in [Amir, 
2000], even if modules are highly cohesive, they are not lowly 
coupled, due to the dependence between objects in the rea- 
soning process defined there. We do not investigate this fur- 
ther here, but conjecture that this could be done there by, dur- 
ing the reasoning process, avoiding passing to a module a 
formula of a type different from those it contains. 

The present work generalizes and extends Pirri and Reiter's 
result to the case where Stat 7^ and both [Pirri and Reiter, 
1999; Amir, 2000] where the syntactical restriction on effect 
laws is not made. This gives us more expressive power, as we 
can reason about inexecutabilities, and a better modularity in 
the sense that we do not combine formulas that are conceptu- 
ally different (viz. executabilities and inexecutabilities). 

8 Conclusion 

We have established a link between knowledge engineering 
and software engineering showing that many of the concepts 
and techniques developed for the latter are useful in the de- 
sign and maintenance of domain descriptions. In particular, 
with the concepts of cohesion and coupling we get better cri- 
teria for domain description evaluation. 

Our central hypothesis is that the different types of axioms 
should be neatly separated and only interfere in one sense: 
state constraints together with action laws may have conse- 
quences that do not follow from the action laws alone. The 
other way round, action laws should not allow to infer new 
state constraints, effect laws should not allow to infer inexe- 
cutability laws, etc. 

At first glance, because of Stat's interaction with other 
modules, it could be said that domain descriptions described 
in our way do not completely minimize coupling. However, 
given the intrinsic nature of Stat, observe that we cannot do 
otherwise: in the same way it is not possible to write com- 
pletely decoupled methods (or the program will not work!), 
we cannot have totally decoupled domain descriptions (un- 
less, of course, we constrain ourselves to domains without 
ramifications like in [Pirri and Reiter, 1999]). 

It could be argued that unintuitive consequences in domain 
descriptions are mainly due to badly written axioms and not 
to the lack of modularity. True enough, but what we have 
presented here is the case that making a domain description 
modular gives us a tool to detect at least some of such prob- 
lems and correct it. (But note that we do not claim to correct 
badly written axioms automatically and once for all). Besides 
this, having separate entities in the ontology and controlling 
their interaction help us to localize where the problems are, 
which can be crucial for real world applications. 
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